The 640 MEG Shareware Studio 2

home *** CD-ROM | disk | FTP | other *** search

/ The 640 MEG Shareware Studio 2 / The 640 Meg Shareware Studio CD-ROM Volume II (Data Express)(1993).ISO / prog / sifver1b.zip / SIFVER.DOC < prev next >

Wrap

Text File | 1991-10-01 | 30KB | 513 lines

SIFVER (c) 1991 Version 1.0B Beta Shareware Information File Verification Program by Paul Scanlon - programming/coding and Jim Hood - SIF concept/file format design Paul Scanlon can be reached at: (805) 272-4827 38354 - 17th ST E #C, Palmdale, CA 93550 Jim Hood can be reached at: (206) 236-0470 PO BOX 1506, Mercer Island, WA 98040 ---------------------------------------------------------------- Detailed Description ---------------------------------------------------------------- SIFVER (for Shareware Information File Verifier), is a utility to aid the software developer in creating a correct README.SIF file. A README.SIF file is similar to a README documentation file (ASCII text) which many shareware packages use, however, the SIF file format is precisely standardized and offers advantages to ALL shareware authors, BBS systems and shareware vendors. The primary focus of a README.SIF file is to standardize a minimum amount of documentation information about any shareware package which all authors, vendors, BBS systems and other can use reliably. A standardized README.SIF file format SHARED AND DEVELOPED by vendors, authors and BBS systems produces rather remarkable advantages which will be discussed shortly. SIFVER is designed to create a unique 8 digit verification number, embeding this number into a SIF file, which can later be verified by a Shareware vendor, BBS or others who routinely work with shareware. SIFVER accepts a STANDARDIZED file prepared in ASCII text, called a README.SIF, and certifies the file for compliance with standard SIF information content. A README.SIF text file may be produced for any shareware or public domain program. The SIF file name must be README.SIF and is an ordinary ASCII text file which can be generated by any word processor in ASCII text mode. The standardized name for the file, README.SIF, will aid in standarizing the shareware industry. Vendors can always find the SIF file without wading thru dozens of other possible DOC or TXT files. In addition, a vendor or BBS will always know that a STANDARDIZED content and style of information will be available which leads to the possibility of rapid, highly automated extraction of SIF information from large quantities of shareware disks! Soon automated programs will search all disks and packages for the presence of a SIF file and automatically extract documentation information directly to a central database for use by the shareware vendor or BBS. The README.SIF file produced by SIFVER contains a unique CRC verification number at the end of the file which represents an "authenticity check" for compliance with a precisely standardized SIF file format. If a file does not comply with the README.SIF format, SIFVER will not allow an "authentication number" at the end of the file. Above all, SIFVER is simple and elegant in design and use. The README.SIF file does NOT preclude other files such as the existing README or README.TXT or MANUAL.TXT which shareware authors and others are encouraged to use in addition to the README.SIF file produced by SIFVER. Further, the authors of SIFVER encourage suggestions or changes to the concept so that the SIF file format and SIFVER program evolve constructively to serve the needs of the shareware industry. The README.SIF file format is placed in the public domain. SIFVER, the software program, is shareware and is NOT placed in the public domain and remains a copyrighted program. Registration/payment information will be discussed. A discussion of "encouragements and inducements" for vendors, authors and BBS systems to use this new format is also presented. ---------------------------------------------------------------- Operation of SIFVER ---------------------------------------------------------------- Using SIFVER is very easy. Place SIFVER into any directory where DOS may access it, log into the directory containing an ASCII text file named README.SIF and enter: SIFVER at your DOS prompt. For the benefit of users, a file named READSIF.FMT (README SIF BLANK FORM) is contained with this package. It is essentially a "blank form" in ASCII which can be loaded into your word processor or text editor and then "filled out." Be sure to rename your text file README.SIF when you are ready to test and verify it. SIFVER will read in the README.SIF file and examine the contents and format. If SIFVER finds the SIF file to be correct, SIFVER will add 3 additional lines to the file, with the first of these containing a SIF verification number to signify an "authenticated and verified" SIF format file. An example of the three lines which will be added follows: :SIF Shareware Information File Verified # : F00007CA <───┐ The SIF Verifier 1.0B by Paul Scanlon and Jim Hood (c) 1991 <──┐│ :Registration Number: UNREGISTERED COPY OF SIF VERIFIER <─┐││ │││ This line (3) contains the registration number of registered │││ versions. ───────────────────────────────────────────────────┘││ ││ This line (2) contains the version number, authors and ││ copyright date. ───────────────────────────────────────────────┘│ │ This line (1) contains the SIF verification number and will │ always be 8 digits. This number will be matched by the vendor │ upon receiving the SIF file, for verification that the SIF file │ contains all mandatory information and the SIF file is in the │ correct format. This number will also be checked, and if they │ do NOT match, an error will occur. ─────────────────────────────┘ SIFVER has a second usage, that is, for the verification of a previously verified (or supposedly verified) SIF file. In this test (verification), the SIF file is checked, as though, for the first time, then the SIF verification string of the file is matched with the new string. If the new string and old match, SIFVER will exit with a success announcement, otherwise it will exit with the type or category of failure. To place SIFVER in the second mode, enter: SIFVER V at the DOS prompt. SIFVER must either be in the current directory or in a directory specified by the path. The README.SIF file must be in the current directory. SIFVER will check the format of the last 3 lines to assure that SIFVER has indeed actually made a check originally. If these last 3 lines (see above) are modified, or placed there by some other program, and do NOT match exactly, an error will be generated. The SIF verification number is made up of a combination of file size, number of lines in the file, and number of bytes contained in the fields. It is a highly unique CRC verification number. SIFVER version 1.0B is a beta version, and as such is being distributed at a very low registration fee. Those who wish to become active users of the SIF verifier process, and would like to send us suggestions and be placed on our mailing list for future versions and enhanced utilities, please send us a $5 fee. This money is only for aiding in the material and shipping fee for sending out notices of new versions and utilities. Some exciting additional products forthcoming include: SIFGEN which will generate an entire SIF file, prompting the Author/Developer for all field data. When executed to completion, this program will generate a SIF verification number matching any which would be generated by SIFVER. SIFXTR which will extract specified fields, placing them into a specified CR delimited file. This product will, in some version, also extract the data to a DBASE structured file. This is a product BBS sysops and shareware vendors will find desirable. As the need arrises, we will develop additional tools and utilities to aid in maintaining and developing SIF files. ---------------------------------------------------------------- Format of a README.SIF text file ---------------------------------------------------------------- All lines are 70 chars long, with margins of 5 chars and 75 chars. Each Field is separated by a blank line (empty) including the last line. The following is a list of bytes (characters) available for use by Author/Vendor in each field type of a SIF file. Each field name begins and ends with a colon. Some fields are required (e.g., name of program) other fields are optional and may be left blank (e.g., Fax telephone number of author.) The name(s) and constructions of these fields have been arrived at by careful consultation with a large variety of vendors and BBS systems. An example "filled in" SIF file is also presented. Maximum size Field name Bytes Lines Title ----------------------------------- 126 2 :PROGRAM NAME: 25 1 :VERSION: 59 1 :COPYRIGHT: 1 1 :SHAREWARE/PUBLIC DOMAIN/FREEWARE/COMMERCIAL (S,P,F,C): 49 1 :REGISTRATION FEE(S): 187 3 :REGISTRATION INCLUDES: 2 1 :PART NUMBER: 2 1 :TOTAL PARTS: 700 10 :CATEGORY: 1050 15 :HARDWARE REQUIREMENTS: 700 10 :SOFTWARE REQUIREMENTS: 40 1 :1 LINE DESCRIPTION: 140 2 :2 LINE DESCRIPTION: 2030 29 :LONG DESCRIPTION: 980 14 :INSTALLATION INSTRUCTIONS: 980 14 :STARTUP INSTRUCTIONS: 60 1 :KEYWORDS: 2030 29 :FILES ON THIS DISK AND DESCRIPTION: 57 1 :AUTHOR NAME: 70 1 :AUTHOR COMPANY NAME: 560 10 :AUTHOR/COMPANY ADDRESS: 52 1 :AUTHOR DAY PHONE: 52 1 :AUTHOR EVE PHONE: 58 1 :AUTHOR FAX: 48 1 :AUTHOR COMPUSERVE ID: 53 1 :AUTHOR GENIE ID: 12 1 :SUGGESTED BBS NAME: 57 1 :LAST UPDATE: 980 14 :GENERAL DESCRIPTION/AUTHORIZATION INFO: 2030 29 :ASP DISTRIBUTION/AUTHORIZATION INFO: 2030 29 :SPECIAL AUTHOR COMMENTS: 2030 29 :VENDOR PROCESSING REMARKS: 70 1 :SPELL/VIRUS CHECK VERIFIED: -------------------------------------------------------------------- 17320 257 <---- T O T A L S ---------------------------------------------------------------- Contents of a sample README.SIF file ---------------------------------------------------------------- :PROGRAM NAME: SEBFU :VERSION: 4.0.0 :COPYRIGHT: 1989-1991 :SHAREWARE/PUBLIC DOMAIN/FREEWARE/COMMERCIAL (S,P,F,C): S :REGISTRATION FEE(S): $19.95 :REGISTRATION INCLUDES: Additional utilities and enhancements :PART NUMBER: 1 :TOTAL PARTS: 1 :CATEGORY: Batch Utilities :HARDWARE REQUIREMENTS: Any PC / XT /AT /386 /486 :SOFTWARE REQUIREMENTS: MSDOS / PCDOS 2.x and up :1 LINE DESCRIPTION: Over 80 powerful batch file utilities :2 LINE DESCRIPTION: Over 80 powerful batch file utilities, which add keyboard input, cursor location, windowing, floppy testing, and much more. :LONG DESCRIPTION: Over 80 powerful batch file utilities, which add keyboard input, cursor location, windowing, floppy testing, send printer control strings, check for system device drivers, perform simple math, and more. Comes with an easy to use editor. :INSTALLATION INSTRUCTIONS: Type EASYINST :STARTUP INSTRUCTIONS: NONE :KEYWORDS: BATCH, UTILITY, DOS :FILES ON THIS DISK AND DESCRIPTION: EASYINST.EXE Installation system LHA.* Archive extraction system SEBFU40.LZH Archived SEBFU :AUTHOR NAME: Paul Scanlon :AUTHOR COMPANY NAME: Scanlon Enterprises :AUTHOR/COMPANY ADDRESS: 38354 17th St. E, Palmdale, CA 93550 :AUTHOR DAY PHONE: (805) 272-4827 :AUTHOR EVE PHONE: (805) 272-4827 :AUTHOR FAX: (805) 274-0040 (call by voice first) :AUTHOR COMPUSERVE ID: :AUTHOR GENIE ID: :SUGGESTED BBS NAME: SEBFU40.ZIP :LAST UPDATE: 9/15/91 :GENERAL DESCRIPTION/AUTHORIZATION INFO: Vendors are hereby granted the right to distribute SEBFU 4.0, provided the vendor follows standard Shareware distribution guidelines. :ASP DISTRIBUTION/AUTHORIZATION INFO: :SPECIAL AUTHOR COMMENTS: :VENDOR PROCESSING REMARKS: :SPELL/VIRUS CHECK VERIFIED: WordStar 5.0 9/15/91 / Viruscan 6.7A :SIF V1.0 Shareware Information File Verified #: 78H08KS2 The SIF Verifier by Paul Scanlon and Jim Hood (c) 1991 :Registration Number: UNREGISTERED COPY OF SIF VERIFIER ---------------------------------------------------------------- Questions ---------------------------------------------------------------- What are the REAL chances of the SIF file format becoming a standard? 5 Large vendors and 16 Large BBS systems have told us they will promote the standard and encourage other vendors and BBS systems to consider it. The chances are that SIF (or something like it) will sooner or later happen because it is needed! How might vendors and BBS sysops encourage the README.SIF standard? Many vendors already send out a letter of acknowlement to an author when they receive a disk. The letter might suggest that authors who submit a README.SIF with their programs would receive a MORE RAPID EVALUTION of a disk and possible speedy inclusion in that vendor's catalog. Or vendors could make the recommendation that an author MUST resubmit the program with a README.SIF before evaluation can begin and include an offer to send a disk copy of SIFVER for a small fee (e.g., $2.00) or note BBS systems where SIFVER may be downloaded. In general, encouragement is better than direct threat! The tradeoff is simple, once all authors use a standard README.SIF file format - just as we all use PKZIP(tm) - then time and energy are saved and shareware is improved. We intend to allow the SIF file format to evolve flexibly to serve the industry and to regularly upgrade the SIF format if sufficient need is apparent. Why should authors use SIFVER? Because it is a simple concept which all authors and vendors have needed for some time. Because it will speed the evaluation and acceptance of your program by vendors. Because it will ultimately standarize the shareware industry and increase registrations. Because you can continue to use an existing README file or other documentation files in addition to the README.SIF. Because we are shareware authors ourselves and want to improve your chances of program acceptance and REGISTRATIONS. Where does this all lead? One of the future plans for SIF technology is a SIF extraction program which all shareware vendors can use which will DRAMATICALLY decrease the workload for vendors. As an example, when a vendor receives disk submissions from authors each day in the mail, all disks are simply placed in succession into a disk drive where the README.SIF file is automatically located, catalogued and added to a database of programs. Long descriptions are added to that vendor's catalog, if interesting, the program data is sent on to the appropriate shareware reviewer. Authors will be assured that program descriptions and version numbers are reasonably accurate in vendor catalogs and vendors will be spared the "hunt and search" for program documentation information! One could envision a software program which individual vendors might design. This small program would be used by an end user or customer and would start the disk, bring up pertinent information about the disk (extracted from the README.SIF) and guide the user through program descriptions, installation and author comments. All disks would start and display information intended by the author in the author's own words! Must the README.SIF be on the same disk as the main program? No. It could arrive on a separate disk if necessary. If possible, the README.SIF should be on the same disk as the main program, but this is only a recommendation. What about the thousands of existing shareware programs which currently lack a README.SIF? Operationally this is a difficult issue. One solution, although not a perfect one, would be for vendors to send authors a short postcard noting that further updates to their program should be accompanied by a README.SIF. Another suggestion would be for vendors or SYSOPS to manually add a README.SIF to an existing package. That README.SIF then becomes public domain for all to use. Still another idea is to require a README.SIF for a package before it can be submitted. It will probably take 2 or 3 years for the process to take hold. Remember the conversion process from ARC archived files to ZIP archived files? It was fairly rapid because IT MADE SENSE and improved shareware distribution in some way. In last analysis we would simply suggest that if a package lacks a README.SIF, one should be constructed from existing documentation available on the disk and installed as a matter of simple common sense. Large vendors such as PC-SIG routinely add small text files to existing programs which are text information files about the program. To date FEW AUTHORS have objected to this defacto "additional text information" placed on a disk by a vendor. Once I create a README.SIF file is its content public domain for other vendors and BBS systems to use? Yes. Even if you are a vendor who creates the file, other vendors and BBS systems are allowed to use the information for the benefit of the industry. This is a requirement you must accept as a licensing agreement to use SIFVER. If you want to retain a copyright to certain text information, simply use a conventional README.TXT or README.DOC file (or other file name) and place your copyrighted text information there - but NOT in the SIF file whose contents and format remain public domain for ALL to use. Obviously the author of a specific package has the right to designate his or her "approved" version of a SIF file and can by telephone or in writing supply both the "approved" SIF file as well as the authentication number generated by SIFVER. However, if the author cannot be found or does not have interest in preparing a SIF file, this minimum amount of documentation information is generally a reasonable expectation of a software package and should not, from a practical standpoint, infringe on an author's copyright or program descriptions. What if an author declines to use a SIF file? If an author specifically prohibits the inclusion of a SIF file, he or she should so state in the main program documentation or by contacting vendors directly. ------------------------------------------------------------- Letter from Exec-PC BBS, Bob Mahoney ------------------------------------------------------------- This letter is copyrighted to Bob Mahoney. The authors of the SIF package do not make copyright claim upon the information which follows and reprint this as a courtesy to possible SIF users and to Mr. Mahoney of Exec-PC BBS to show that LARGE BBS systems do indeed have interest in a standardized README.SIF format. From Bob Mahoney, Exec-PC BBS 5/21/91 Voice number: 414-789-4200 BBS number : 414-789-4210 Regarding the SIF (Shareware Information File) proposed README file format for shareware distribution. From Bob Mahoney: My response to your proposal is 100% positive. I have no suggestions for any basic changes in concept or intent of the project. It is about time someone in our industry had the guts and energy to put something like this together - I guess we all wanted it, but did not have the time or inspiration to put it together. Don't get me wrong - shareware authors are the center of my world, they make my BBS possible . . . BUT, a few times I have not even been able to figure out what some shareware submissions do, let alone place them on the BBS and give them an accurate description. They have ended up in the "used diskette" pile without being placed on our BBS! Exec-PC would use your SIF system. We would also push it and perhaps give preferential treatment to shareware submissions using it. We would place info on it in our bulletins and would be glad to publicize the concept to help get it rolling. My only suggestions: 1. Put a limit of 53 characters as the maximum width on the short description. If 53 is too strange, 50 will do for most systems. Encourage the authors to really use the short description. In many, many cases the short description is the *ONLY* chance they will have to sell their product to many people. I cannot overemphasize the importance of the short description. Most authors seem to put all their literary effort into the long description. That's ok, but you've gotta grab 'em with that short description. Example of a typical bad short description: SHAREWARE WORD PROCESSOR, LOTS OF FEATURES Example of an improved short description: WP WORD PROCESSOR PULL DOWN MENUS WYSIWG, INTUITIVE! Short description hints: Use the full width! Squeeze in keywords. As shown above, some people scan for "WP" when looking for word processors. Skip the punctuation - you are trying to hit people with the right magic words to get their interest, so squeeze in as many of those colorful or technical words as possible. 2. Limit the long description to 100 lines maximum, perhaps less for many bulletin boards. Limit the width of long descriptions to 75 characters since that is a limit on many message editors on online systems. Long description hints: Don't write a book. Write a short, concise description of what your product is. In the first sentence or two you must assume the reader has never heard of your product, so you must introduce it. Follow your short overview and introduction with a concise list of primary features. The features should stimulate thoughts of benefit in the mind of the reader. Order the features from most important to least important. Most people will read the first 3 or 4 features and will start to make up their mind about the file before reading the rest of the list. Ok, that is all the input I have at this time. The plan looks good to me. None of the SIF entries look frivolous, but I do think you have enough info there and should not listen to suggestions to add any more data to it - it is full of enough data as is. Bob Mahoney Exec-PC BBS